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   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.
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Abstract

   The IPsec series of protocols makes use of various cryptographic
   algorithms in order to provide security services.  The Encapsulating
   Security Payload (ESP) and the Authentication Header (AH) provide two
   mechanisms for protecting data being sent over an IPsec Security
   Association (SA).  To ensure interoperability between disparate
   implementations, it is necessary to specify a set of mandatory-to-
   implement algorithms to ensure that there is at least one algorithm
   that all implementations will have available.  This document defines
   the current set of mandatory-to-implement algorithms for ESP and AH
   as well as specifying algorithms that should be implemented because
   they may be promoted to mandatory at some future time.
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1.  Introduction

   The Encapsulating Security Payload (ESP) and the Authentication
   Header (AH) provide two mechanisms for protecting data being sent
   over an IPsec Security Association (SA) [IPsec, ESP, AH].  To ensure
   interoperability between disparate implementations, it is necessary
   to specify a set of mandatory-to-implement algorithms to ensure that
   there is at least one algorithm that all implementations will have
   available.  This document defines the current set of mandatory-to-
   implement algorithms for ESP and AH as well as specifying algorithms
   that should be implemented because they may be promoted to mandatory
   at some future time.

   The nature of cryptography is that new algorithms surface
   continuously and existing algorithms are continuously attacked.  An
   algorithm believed to be strong today may be demonstrated to be weak
   tomorrow.  Given this, the choice of mandatory-to-implement algorithm
   should be conservative so as to minimize the likelihood of it being
   compromised quickly.  Thought should also be given to performance
   considerations as many uses of IPsec will be in environments where
   performance is a concern.

   Finally, we need to recognize that the mandatory-to-implement
   algorithm(s) may need to change over time to adapt to the changing
   world.  For this reason, the selection of mandatory-to-implement
   algorithms is not included the main IPsec, ESP, or AH specifications.
   It is instead placed in this document.  As the choice of algorithm
   changes, only this document should need to be updated.

   Ideally, the mandatory-to-implement algorithm of tomorrow should
   already be available in most implementations of IPsec by the time it
   is made mandatory.  To facilitate this, we will attempt to identify
   such algorithms (as they are known today) in this document.  There is
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   no guarantee that the algorithms we believe today may be mandatory in
   the future will in fact become so.  All algorithms known today are
   subject to cryptographic attack and may be broken in the future.

2.  Requirements Terminology

   Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and
   "MAY" that appear in this document are to be interpreted as described
   in [RFC2119].

   We define some additional terms here:

   SHOULD+     This term means the same as SHOULD.  However, it is
               likely that an algorithm marked as SHOULD+ will be
               promoted at some future time to be a MUST.
   SHOULD-     This term means the same as SHOULD.  However, it is
               likely that an algorithm marked as SHOULD- will be
               deprecated to a MAY or worse in a future version of this
               document.
   MUST-       This term means the same as MUST.  However, we expect
               that at some point in the future this algorithm will no
               longer be a MUST.

3.  Algorithm Selection

   For IPsec implementations to interoperate, they must support one or
   more security algorithms in common.  This section specifies the
   security algorithm implementation requirements for standards-
   conformant ESP and AH implementations.  The security algorithms
   actually used for any particular ESP or AH security association are
   determined by a negotiation mechanism, such as the Internet Key
   Exchange (IKE [RFC2409, IKEv2]) or pre-establishment.

   Of course, additional standard and proprietary algorithms beyond
   those listed below can be implemented.

3.1.  Encapsulating Security Payload

   The implementation conformance requirements for security algorithms
   for ESP are given in the tables below.  See Section 2 for definitions
   of the values in the "Requirement" column.
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3.1.1.  ESP Encryption and Authentication Algorithms

   These tables list encryption and authentication algorithms for the
   IPsec Encapsulating Security Payload protocol.

      Requirement    Encryption Algorithm (notes)
      -----------    --------------------
      MUST           NULL (1)
      MUST-          TripleDES-CBC [RFC2451]
      SHOULD+        AES-CBC with 128-bit keys [RFC3602]
      SHOULD         AES-CTR [RFC3686]
      SHOULD NOT     DES-CBC [RFC2405] (3)

      Requirement    Authentication Algorithm (notes)
      -----------    ------------------------
      MUST           HMAC-SHA1-96 [RFC2404]
      MUST           NULL (1)
      SHOULD+        AES-XCBC-MAC-96 [RFC3566]
      MAY            HMAC-MD5-96 [RFC2403] (2)

   Notes:

   (1) Since ESP encryption and authentication are optional, support for
       the two "NULL" algorithms is required to maintain consistency
       with the way these services are negotiated.  Note that while
       authentication and encryption can each be "NULL", they MUST NOT
       both be "NULL".
   (2) Weaknesses have become apparent in MD5; however, these should not
       affect the use of MD5 with HMAC.
   (3) DES, with its small key size and publicly demonstrated and open-
       design special-purpose cracking hardware, is of questionable
       security for general use.

3.1.2.  ESP Combined Mode Algorithms

   As specified in [ESP], combined mode algorithms are supported that
   provide both confidentiality and authentication services.  Support of
   such algorithms will require proper structuring of ESP
   implementations.  Under many circumstances, combined mode algorithms
   provide significant efficiency and throughput advantages.  Although
   there are no suggested or required combined algorithms at this time,
   AES-CCM [CCM], which has been adopted as the preferred mode for
   security in IEEE 802.11 [802.11i], is expected to be of interest in
   the near future.
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3.2.  Authentication Header

   The implementation conformance requirements for security algorithms
   for AH are given below.  See Section 2 for definitions of the values
   in the "Requirement" column.  As you would suspect, all of these
   algorithms are authentication algorithms.

      Requirement    Algorithm (notes)
      -----------    ---------
      MUST           HMAC-SHA1-96 [RFC2404]
      SHOULD+        AES-XCBC-MAC-96 [RFC3566]
      MAY            HMAC-MD5-96 [RFC2403] (1)

   Note:

   (1) Weaknesses have become apparent in MD5; however, these should not
       affect the use of MD5 with HMAC.

4.  Security Considerations

   The security of cryptographic-based systems depends on both the
   strength of the cryptographic algorithms chosen and the strength of
   the keys used with those algorithms.  The security also depends on
   the engineering and administration of the protocol used by the system
   to ensure that there are no non-cryptographic ways to bypass the
   security of the overall system.

   This document concerns itself with the selection of cryptographic
   algorithms for the use of ESP and AH, specifically with the selection
   of mandatory-to-implement algorithms.  The algorithms identified in
   this document as "MUST implement" or "SHOULD implement" are not known
   to be broken at the current time, and cryptographic research so far
   leads us to believe that they will likely remain secure into the
   foreseeable future.  However, this is not necessarily forever.  We
   would therefore expect that new revisions of this document will be
   issued from time to time that reflect the current best practice in
   this area.

5.  Acknowledgement

   Much of the wording herein was adapted from RFC 4307, "Cryptographic
   Algorithms for Use in the Internet Key Exchange Version 2", by
   Jeffrey I. Schiller.
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6.  Changes from RFC 2402 and 2406

   [RFC2402] and [RFC2406] defined the IPsec Authentication Header and
   IPsec Encapsulating Security Payload.  Each specified the
   implementation requirements for cryptographic algorithms for their
   respective protocols.  They have now been replaced with [AH] and
   [ESP], which do not specify cryptographic algorithm implementation
   requirements, and this document, which specifies such requirements
   for both [AH] and [ESP].

   The implementation requirements are compared below:

   Old   Old         New
   Req.  RFC(s)      Requirement  Algorithm (notes)
   ---   ------      -----------  ---------
   MUST  2406        SHOULD NOT   DES-CBC [RFC2405] (1)
   MUST  2402 2406   MAY          HMAC-MD5-96 [RFC2403]
   MUST  2402 2406   MUST         HMAC-SHA1-96 [RFC2404]

   Note:

   (1) The IETF deprecated the use of single DES years ago and has not
      included it in any new standard for some time (see IESG note on
      the first page of [RFC2407]).  But this document represents the
      first standards-track recognition of that deprecation by
      specifying that implementations SHOULD NOT provide single DES.
      The US Government National Institute of Standards and Technology
      (NIST) has formally recognized the weakness of single DES by a
      notice published in the 26 July 2004 US Government Federal
      Register (Docket No. 040602169-4169-01) proposing to withdraw it
      as a US Government Standard.  Triple DES remains approved by both
      the IETF and NIST.
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